home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000166_UZTBB@CUNYVM.CUNY.EDU _Wed Jul 7 04:28:32 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  3KB
  1. Received: from Arizona.edu (Hopey.Telcom.Arizona.EDU) by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA11141; Wed, 14 Jul 1993 12:17:12 MST
  3. Received: from CUNYVM.CUNY.EDU (MAILER@CUNYVMV2) by Arizona.edu (PMDF V4.2-13
  4.  #2381) id <01H0J41LCEPC9EG5OZ@Arizona.edu>; Wed, 14 Jul 1993 12:17:01 MST
  5. Received: from CUNYVM.CUNY.EDU (NJE origin UZTBB@CUNYVM) by CUNYVM.CUNY.EDU
  6.  (LMail V1.1d/1.7f) with RFC822 id 1001; Wed, 7 Jul 1993 04:28:56 -0400
  7. Date: Wed, 07 Jul 1993 04:28:32 -0400 (EDT)
  8. From: Abdullah Uz Tansel <UZTBB@CUNYVM.BITNET>
  9. Subject: Rick's message on TSQL standards
  10. To: tsql@cs.arizona.edu
  11. Message-Id: <01H0J6B0XJ1C9EG5OZ@Arizona.edu>
  12. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  13. Content-Transfer-Encoding: 7BIT
  14.  
  15. In his recent message Rick provided three alternatives on TSQL
  16. standards.  There are several points which I would like to bring to
  17. the attention of TDB community:
  18.  
  19. 1. During the workshop we only discussed whether standards for a temporal
  20. extension should be done to SQL2 or SQL3.  Beyond this we have not
  21. discussed any other technical issues and the language features needed.
  22. There was common agreement that temporal standards are needed and that
  23. is where we have stoped.  If I am mistaken please correct me.
  24.  
  25. 2. Definition of temporal standards is an important requirement and it
  26. will be a significant contribution to the field.  I also beleive it iss
  27. urgently needed.  However, defining stabndards involves serious
  28. implications for the tdb field and its future developments and it
  29. should not be done in a rush.  No matter how good our intentions are
  30. there is   the significant danger of making a disservice to  the
  31. tdb field if the standards are not well and thoroughly defined.
  32.  
  33. 3.  In my oponion, email is not the ideal medium for developing
  34. stabdards which are expected to represent consensus.  It requires
  35. elaborate, face to face discussion.  Email can only do the ground
  36. work not the final conclusion.  Given the tight schedule for the
  37. preparation of the workshop report linking this document and
  38. the standards is not reasonable. Especially, incorporating matarial
  39. prepared in a rush to a documnet which represents consunsus
  40. may deliver the wrong and unintended messages to the industry and
  41.  
  42. others.  Are we willing to accept the historical burdon of such respon-
  43. sibilty.
  44.  
  45. 4. In my oponion, the ideal approach is first determinig the requirements
  46. especially language requirements of temporal databases.  These require-
  47. ments should be    determined with broader perspective.  Then, the
  48. standards can be defined accordingly, for SQL2, SQL3, or any other
  49. language you like.  It is even possible to achieve any short term
  50. objective. However, this can not be done in a rush.
  51.  
  52. 5. The above comment may sound negative.  That is not my intention,
  53. I just want the tdb community be aware of these points.  I am not
  54. against extending SQL2 or any other effort.
  55.  
  56. Here are my suggestion:
  57.  
  58. A. Establish a platform for defining tdb language requirements
  59. comprehensively.  Develop the requirements over, say next 6 month.
  60.  
  61. B.  Then form groups for SQL2. SQL3, OODB, etc.
  62.  
  63. C.  Have a meeting in spring to discuss and finalize the findings of
  64. the groups.
  65.  
  66.  
  67. D. Do not link workshop document and standards.
  68.  
  69. The time table is tentative can be modified.  It is an idea.
  70. Comments are welcome.
  71.  
  72. Best wishes
  73. Abdullah Tansel